前兩篇聊到了『完成的定義』與『使用者故事』，其實只是為了講解『驗收條件』（Acceptance Criteria）打底。一個工作項目是否達到客戶對需求的期待？答案就是足『通過』所有驗收條件才算是真正的產生價值。

完成的定義關注的點是『衝刺』中對所有『工作項目』／『使用者故事』的基本要求，而『驗收條件』則是對『工作項目』／『使用者故事』的需求細節進行逐一驗證。一個工作項目是否能如質如期的完成，最重要的一部分就取決於開工前是否有明確的『驗收條件』。

驗收條件的目的

• 描述明確的需求範圍：透過驗收條件的討論，讓團隊了解產品負責人與利益關係人對這個需求的期待，也能讓團隊更明確的了解這個需求的範圍，也方便估計時程與測試涵蓋範圍。
• 描述錯誤的案例處理：透過驗收條件條例出現有需求可以會遇到的限制與錯誤處理方式，開發過程完成期待中的需求比較沒問題，大多數遺漏的部分都是『錯誤／例外處理』。
• 增加共識的討論模式：透過驗收條件的討論，產品負責人與開發團隊，一次又一次的理解需求的目的，確保對需求有相同的了解，才能在最後的展示階段完整的呈現結果。
• 提早列舉出測試案例：驗收條件也是讓測試人員、產品負責人對開發團隊說明之後將進行的測試案例的過程，才不會發生開發團隊做的東西都沒被測試到，需要測試的部分都沒被完整開發。
• 時程工期的有效估計：透過驗收條件討論之後才能更明確的瞭解需求與測試範圍，開發團隊才能對這個需求有更有信心的估計，無論是時間、人力的絕對估計或是點數、大小的相對估計。

驗收條件的寫法

常見驗收條件的寫法有下列幾種

情境式寫法（Scenario-based）

『情境式寫法』的結構包含了五個元素：

1. 情境（Scenario）：描述這個驗收條件的情境
2. 假定（Given）：描述這個驗收條件的預先設定的條件
3. 當（When）：描述這個驗收條件在什麼情況下
4. 然後（Then）：描述這個驗收條件預期會發生的結果
5. 而且（And）：描述這個驗收條件預期會發生的更多結果

舉例來說：

• 『情境』是使用者帳號登入
• 『假定』使用者開啟帳號登入頁面
• 『當』使用者存在的帳號、錯誤的密碼時
• 『然後』登入頁面會秀出提示訊息『密碼錯誤』
• 『而且』登入頁面也會呈現『忘記密碼』的連結

規則式寫法（Rule-based）

所謂的『規則式寫法』是用條列式的方式列出所以需要驗證的測試案例
『測試案例』是使用者帳號登入，驗證規則如下：

1. 使用者輸入正確的帳號、密碼時，可以登入帳號頁面查看帳號資訊。
2. 使用者輸入存在的帳號、但錯誤密碼時，需要秀出提示訊息『密碼錯誤』
3. 使用者輸入不存在的帳號時，需要秀出提示訊息『不存在的帳號』
4. 使用者輸入錯誤的密碼超過三次時，需要秀出提示訊息『密碼已錯誤三次，需要重設密碼（附連結）』

客戶習慣的寫法（Customer-based）

有些客戶可能會用流程圖的方式、心智圖、檢核表的方式寫完成驗收條件，但寫法不是重點，能清楚呈現『驗收條件』的就是好方法。

驗收條件怪味道的七八點

1. 完成後才寫驗收條件：工作項目完成後才進行驗收條件的討論。
2. 鉅細靡遺的驗收條件：驗收條件太過仔細，單一功能就有不同組合的測試。
3. 超出範圍的驗收條件：驗收條件太廣已經超過本次要進行的範圍。
4. 技術細節的驗收條件：驗收條件的不是使用者看到的情境，而是底層的技術細節。
5. 沒有共識的驗收條件：團隊對驗收條件還沒有共識就開工。
6. 無法獨立的驗收條件：這個驗收條件需要其他驗收條件的配合才能進行測試。
7. 充滿變數的驗收條件：測試的條件是充滿變數的，無法模擬的。
8. 單向定義的驗收條件：只由測試人員或產品負責人設計出的驗收條件，開發團隊都事前不知情。

【文思不藏私】敏捷 30 天養成計劃～搶先看